From: mnp!mpaque@NeXT.COM (Mike Paquette)
Newsgroups: comp.sys.next.hardware
Subject: Supporting multiprocessor platforms under NEXTSTEP
Date: 19 Oct 1994 16:18:17 -0500
Reply-To: mnp!mpaque@NeXT.COM

Watching the recent thread of discussion "Re: Dual Pentium and
NeXTStep?" is rather like watching a game of telephone, with
information mutating from one message to the next.  I can't stand it
anymore...

Here's some real information, from press releases, speeches by
assorted officers of NeXT, and whatnot.  Nothing here that can't be
found out by anyone willing to do a little research.

1) The NEXTSTEP Mach kernel is based on Mach 2.0, with a number of
enhancements picked up from Mach 2.5.  The Mach kernel in NEXTSTEP
3.3 will incorporate additional enhancements from Mach 3.0,
particularly in the areas of scheduling and messaging.

2) The Mach kernel is designed to work in a symmetric multiprocessor
environment.  There are two areas that need to be addressed to
implement SMP support (along with several hundred details...).

First, the kernel must be compiled for use with multiple processors.
This causes mutex locks to be compiled into the kernel to serialize
access to critical sections. That's the easy part.

Second, the machine-dependent code needed to manage multiprocessor
initialization, resource management, thread migration, and whatnot
needs to be written.  There is a C language API in the Mach kernel
that covers most of the machine dependencies.

In the case of the Intel platforms, this gets tricky, as there are
now FOUR different specifications kicking around for SMP board
design.  There are two versions of the Intel-led SMP consortium's
spec, another multi-vendor spec, and even a spec from a consortium of
chip set manufacturers.  Three of these specifications have actually
been implemented in hardware to varying degrees.

3) The AppKit is not thread-safe (not even on the old m88k and 601
SMP prototype hardware Mr. Jobs and others have mentioned).  Oh, it's
been thought about, but fundamentally the AppKit is an inappropriate
candidate for multithreaded operation.  The degree of interlocking
required would effectively serialize the entire kit, with no
performance gain (in fact, a net loss!) over the current kit.  Think
of the AppKit as a set of tools used to manipulate the global state
of a GUI, and you may see what I mean.

In general, I think a developer's time and energy would be better
spent decoupling the application's GUI and core functionality,
permitting the GUI to run in one thread, and the core functionality
torun in one or more other threads (or even on a fast back-end
processor through PDO).

         Mike Paquette
=====
I don't speak for NeXT, and NeXT doesn't speak for me.